home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000568_timbl@www3.cern.ch _Thu Jan 14 17:47:51 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  22KB
  1. Return-Path: <timbl@www3.cern.ch>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA13720; Thu, 14 Jan 93 17:47:51 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA11438; Thu, 14 Jan 1993 18:03:03 +0100
  6. Received: by www3.cern.ch (NX5.67c/NX3.0S)
  7.     id AA00591; Thu, 14 Jan 93 18:02:07 +0100
  8. Date: Thu, 14 Jan 93 18:02:07 +0100
  9. From: Tim Berners-Lee <timbl@www3.cern.ch>
  10. Message-Id: <9301141702.AA00591@www3.cern.ch>
  11. Received: by NeXT.Mailer (1.87.1)
  12. Received: by NeXT Mailer (1.87.1)
  13. To: Dan Connolly <connolly@pixel.convex.com>
  14. Subject: Re: HTML todo list
  15. Cc: www-talk@nxoc01.cern.ch
  16. Reply-To: timbl@nxoc01.cern.ch
  17.  
  18.  
  19. My machine crashed from too many wondows and I lost a few unsent mail  
  20. messages with that.  So I may repeat myself at first, up to point 14.
  21.  
  22. Changes to the DTD I have made are in 
  23.  
  24. /hypertext/WWW/MarkUp/HTML.dtd.html
  25.  
  26. Connolly/Current/* is untouched.
  27.  
  28. > Date: Mon, 11 Jan 93 22:36:43 CST
  29. > From: Dan Connolly <connolly@pixel.convex.com>
  30. > 
  31.  
  32.  
  33. > 1. My dictionary lists "markup" as a word, not mark-up.
  34. Fixed
  35. > 2. The PLAINTEXT situation should be logged as a bug against
  36. OK it is but not many servers use it and clients like to be able to  
  37. get source of postscript files for example easily. HTTP2 will fix it.
  38. > 4. HTML should support QUESTION and RESPONSE elements to
  39. > support converting USENET FAQ's to HTML
  40. Too specific I think.
  41. > In http://info.cern.ch/hypertext/WWW/Provider/ShellScript.html
  42. > 5. PLAINTEXT is deprecated. Use PRE, and use a sed script
  43. Done.  text2html.sed on th web under HTML generation tools.
  44. > 6. .../WWW/Tools/HTMLGeneration/dir2html.txt
  45. > This thing doesn't quote attributes; ...
  46. Fixed. 
  47.  
  48. > 7. .../WWW/Tools/HTMLGeneration/ls2html.awk.txt> Quotes around  
  49. HREFS, PLAINTEXT.
  50. Fixed
  51.  
  52.  
  53. > 8. .../WWW/Daemon/Implementation/asis.txt
  54. > Quote HREFS, numeric character references where necessary.
  55. Quote sin online version, original is being rewritten anyway I am  
  56. told.
  57. > 9. http://info.cern.ch/hypertext/WWW/HytelnetGate/src/htn2html.c
  58. > Uses HEADER in stead of HEAD.
  59. Fixed.
  60. > Quote HREFs.
  61. Fixed.
  62. > Special character entities?
  63. > Yeah! It uses numeric character references already!
  64. Does it? You mean entities I think.
  65. > In http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html
  66.  
  67. > 10. Mark-up again
  68. Fixed
  69.  
  70. > 11. This text seems out of place:
  71. OK I have hidden it. :-) Does your spec say it anywhere?
  72.  
  73. > 12. Default text: this node seems to confuse lots of issues.
  74. OK Reference to your doc instead
  75.  
  76. > In http://info.cern.ch/hypertext/WWW/MarkUp/Tags.html
  77. > 13. This text is out of place: 
  78.  
  79. Gone.
  80.  
  81.  
  82. > In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/HEAD.html
  83. > 14. These blurbs should probably quote their element declarations
  84. I have started an HTML.dtd.html with links.
  85.  
  86.  
  87. > In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/TITLE.html
  88. > 15. This seems redundant:
  89. Fixed.
  90.  
  91. > 16. What does this mean?
  92. Elaborated and more sepcific.
  93.  
  94.  
  95. > 17. Should the TITLE element be CDATA, RCDATA, or PCDATA?
  96. > If we want to be able to use Latin chars in the title,
  97. > it can't be CDATA. The only difference between RCDATA
  98. > and PCDATA (with no subelements allowed) is that comments
  99. > are recognized in PCDATA, whereas they are just regular
  100. > data in RCDATA.
  101.  
  102. Good point.
  103.  
  104.  - If we specify Latin 1 as the base set, can't wehave latin 1
  105.    characters in CDATA?
  106.  
  107.  - If we can't, then I guess we use PCADATA as it would be the
  108.    only place except for <XMP> and <LISTING> where we can use
  109.    RCDATA.
  110.    
  111.  
  112. > In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/ISINDEX.html
  113. > 18. The word "Format" connotes lexical details, which are discussed
  114. > elsewhere. I endorse the use of examples, but I'd like to keep
  115. > the model of
  116. >     SGML source ==parser==> ESIS ==WWW semantics==>formatted  
  117. output
  118. > consistent. The WWW semantics processor doesn't deal with <>'s etc.
  119. > It just sees the presence of the ISINDEX element and acts  
  120. accordingly.
  121.  
  122. Yes.  OK.  But I want as I said before (unless the crash lost the
  123. message) to have two documents out of this. One is the HTML spec for  
  124. MIME IANA registration.  The other is a readable document which is  
  125. NOT 100% a precise refernce document but can be read by human beings  
  126. WITHOUT SGML knowledge.  I can guess that this document will have 10  
  127. times the readership of the other if it is readable, as <10% of the  
  128. people creating HTML will know about SGML CROs etc etc.
  129.  
  130. It is good to have a lot of cross-reference between them.
  131.  
  132. > In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/NEXTID.html
  133. > 19. The status of each element should be noted consistently. e.g.
  134. > Mainstream    Consistently used by past, present, and future  
  135. implementations.
  136. > Deprecated    In use and will be supported, but should be avoided.  
  137. (XMP)
  138. > Obsolete    In use in some documents, but will not be supported.  
  139. (NEXTID)
  140. > Proposed    Not yet in the DTD or widely supported (e.g. LINK)
  141. > Standard    Not yet widely supported, but will be (e.g. PRE)
  142. > Extra        It's legal to ignore these. (e.g. EM)
  143.  
  144.  
  145. We have almost as many categories as elements!  I'd add
  146. Obsolescent    Will be obsolete when the alternative implementation
  147.         (eg HTTP2) is available.
  148.         
  149. I'd make PRE mainstream as there are no implementations for which a  
  150. new PRE-understanding version is not available or easily made  
  151. available. And so cut out "Standard"  OOps I put it in again  
  152. ...see#31.
  153.  
  154. I have made NEXTID Mainstream.  Editors need it: can't do without it
  155. really.  I would perhaps change it to <EDITING NEXTID=z27> if that  
  156. was felt to be more logical.
  157.  
  158. We also need a hook for a version for the checkin/out/lock logic  
  159. DAN(?) proposed.  That was that when you
  160. lock or PUT a document, you specify the version so that a document  
  161. can be PUT or CHECKED IN by a different person to the one who GoT it.
  162. This means the server gives a key, a version or date code, with the  
  163. document. This is all HTTP2 except when a document is stored  
  164. somehwre, passed around and then eventually returned to the server.  
  165. In that case, it needs a place to hold its original version number
  166. on the server.
  167.  
  168. <EDITING NEXTID=z27 CHECKEDOUTAS="19930217234507">
  169.  
  170. Thoughts?
  171.  
  172. > http://info.cern.ch/hypertext/WWW/MarkUp/Elements/LINK.html
  173. > 20. How many of these are allowed? I could change
  174. Any non-negative integer
  175. > ... <!ELEMENT HEAD - -  (TITLE? & ISINDEX? & NEXTID? & LINK*)>
  176. > I don't know if the latter is legal SGML. I'd have to try
  177. > it out.
  178. I think that's what we want.
  179.  
  180. > 21. Link types are not well defined. The only reason to put
  181. > something in a public specification is so everybody can agree
  182. > on some semantics. If there are no semantics to agree on,
  183. > why include the TYPE attribute? (It's status is at best
  184. > "proposed" in my mind, though it's in the DTD.)
  185.  
  186.  
  187. Yes and no.  We need some well-define link type but we also need this  
  188. as a hook for the future which we haven't enugh experience.  Link
  189. types whould be registered.
  190.  
  191. This is a flexibility point, but it must be firm ... like
  192. a towing ball on the back of your pickup you want to be able
  193. to connect anything onto it but you want it well fixed onto the  
  194. truck!
  195.  
  196. But I want to make it REL instead of TYPE as people think TYPE
  197. refers to the object type of the desdtination object rather than the  
  198. link.  (From messages on this list).
  199.  
  200. > In http://info.cern.ch/hypertext/WWW/MarkUp/Headings.html
  201. > 22. "(at least six)" -- how about exactly six? Though I've
  202. > seen a lot of style guides that frown on anything more than 4.
  203.  
  204. I agree.  I wuld frown ony anything over 3 in a hypertext document.
  205. However, it is useful to generate a great big HTML document by
  206. concatenating little ones, demoting their heading levels. You then  
  207. print the big document. This generates up to 6 easily.  Maybe we  
  208. should go to 9 but frown on >4.
  209.  
  210. > In http://info.cern.ch/hypertext/WWW/MarkUp/SGML.html
  211. > 23. We should give at least one complete reference to the standard, 
  212.  
  213. Done.
  214.  
  215. > 24. In the Archive section, we could metion comp.text.sgml,
  216. > the SGMLs parser materials, and the ifi.uio.no archive.
  217.  
  218. Link put in cruely.
  219.  
  220. > In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/A.html
  221. > 25. All attribute values have to be quoted, including NAME.
  222. > The example is wrong.
  223.  
  224. I have cahnged NAME to ne a NAME -- ie doc-wide unique which it must   
  225. be. Numberic ones are then not valid but I donb't generate them any  
  226. more.  I think that we should stick to the intended ID system. In the  
  227. future, we can think about IDs on many other elements.
  228.  
  229. > 26. The TYPE attribute hardly seems worth mentioning. In the DTD,
  230. > it's a NAME, not just any old string.
  231.  
  232. I have made it REL as I said above and I think it is very important.
  233.  
  234. > 27. We should look at modeling anchors as HyTime linkends
  235. > and/or ilinks.
  236.  
  237. Yes I agree when someone has time to get into that.
  238.  
  239. > 28. We should look at modeling the LINK element as a HyTime
  240. > construct as well.
  241. Ditto.
  242.  
  243. > In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/P.html
  244. > 29. I don't like the use of "exact representation" here:
  245. OK we stick to "rendering" for that
  246.  
  247. > 30. Where are P's allowed? In the DTD, they're allowed in:
  248. > HTML, BODY, ADDRESS, BLOCKQUOTE, PRE but not in HEAD, A,
  249. > CODE, SAMP, etc.
  250.  
  251. That's right.  They are not in the CERN implementations allowed in  
  252. <DL> or <UL> etc, but they would be useful in those.
  253. Comments?
  254.  
  255. > In http://info.cern.ch/hypertext/WWW/MarkUp/Lists.html
  256. > 31. Ordered lists: Obsolete or Standard?
  257.  
  258. Standard. Bother I thought we'd got rd of that! (The next editor will  
  259. turn them into unordered lists at the moment but I can fix that)
  260.  
  261.  
  262. > 32. "The format is:" Here again, this is an example, but it's
  263. > hardly a specification of the format of a UL element.
  264.  
  265. Ok. example.
  266.  
  267. > 33. What does this mean?
  268. > The opening list tag  must be immediately
  269. > followed by the first list element.
  270.  
  271. (LI | (A|%text)+)  in SGML I suppose just as you say.
  272. You can't
  273.     <UL>and here they all are:
  274.     <LI>The first..
  275.     <LI>the second
  276.     </UL>
  277.  
  278.  
  279. > 34. The important difference between UL, MENU, and DIR is not
  280. > how they are displayed, but their semantic meanings. A MENU
  281. > is a list of things to choose from. A DIR is a list of names
  282. > in a directory.
  283.  
  284. Yes and no.  I too like logical definitions -- I am sold on semantic  
  285. markup but HTML is to cover a vast range of data and semantics. MENU
  286. These things are NOT necessarily what their names suggest -- many a  
  287. selectable menu is set out as a DIR or a DL. The element names are
  288. mnemonic only.  The blurb talks about how much text is in the  
  289. paragraphs.
  290.  
  291. > 35. We could also make this semantic distinction between PRE,
  292. > XMP, and LISTING, were it not for the syntactic confusion
  293. > surrounding XMP and LISTING.
  294.  
  295. We coudl but we are deprecating XMP and LISTINg and PRE will do for
  296. all.  You can only be very semantic in a very narrow application.
  297. This is not one.
  298.  
  299. > 36. Get rid of this:
  300. Gone
  301.  
  302. > In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/PRE.html
  303. > 37. Wording of the newline documentation:
  304. > Line boundaries within the text are
  305. Reworded with "render"
  306.  
  307. > 38. Semantics of newlines in PRE. Given the current DTD, a newline
  308. > after the PRE start tag or before the PRE end tag is not reported
  309. > by an SGML parser.
  310. > 
  311.  
  312. > I think I can cook up some magic SHORTREF declarations that will
  313. > cause the SGML parser to report the newlines (possibly as P tags).
  314. > [This would obviate the need for special newline processing code
  315. > in libHTML]
  316. > 
  317.  
  318. > In any case, I'd suggest that ALL NEWLINES REPORTED BY THE SGML
  319. > PARSER IN THE PRE ELEMENT BE DISPLAYED AS LINE BREAKS. That only
  320. > leaves the issue of which newlines are reported, which is governed
  321. > by the SGML standard.
  322.  
  323. ... and with the issue of explaining the end result to the
  324. simple HTML writer and to me without our needing to call on the
  325. model of the SGML engine and application. Awaiting the results
  326. of your tests with SHORTREF.
  327.  
  328. > 39. I don't like the way this is worded:
  329. > The <p> tag should not be used.
  330. Ok done
  331.  
  332. > 40. "... character character highlighing elements may be used."
  333. > Ack! I don't recommend this! Hmmm... maybe only the B, I, and U
  334. > elements. This certainly conflicts with the current DTD.
  335.  
  336. Serious point here folks.  There was a great demand for B I U
  337. for man pages and the like. Why prohibit anything other than TT.
  338. or to keep it simple, allow anything and mention TT should not be  
  339. used, and the constraints of fixed width may limit the ability to  
  340. render some highlighting.
  341.  
  342. I have introduced %htext noting that text always occurred with A.
  343. I hope I have done it right.
  344.  
  345.  
  346. > In http://info.cern.ch/hypertext/WWW/MarkUp/Highlighting.html
  347. > 41. These have status "Extra"
  348. > Where not supported by implementations,
  349. > like all tags, these should be ignored.<p>
  350. > 
  351.  
  352. > This should be a warning to providers that some information may
  353. > be lost on some browsers.
  354. > 
  355.  
  356. > 42. (Definition of these and reference
  357. > - Dan?)
  358. > They come from TeXinfo.
  359. Thanks
  360.  
  361. > 43. I left the TeXinfo @file element out. I don't remember why.
  362. > It might have been an oversight. Do we want it in there?
  363.  
  364. No too sepcific. We have enough.
  365.  
  366. > 44. Examples (TBD) see complete.html in my stuff.
  367.  
  368. I repeat that I like your examples but I would like them split
  369. into GOOD HTML documents describing bad HTML documents,
  370. with links to the bad documents for testing only.
  371. We don't want people to follow links to the only documentation to  
  372. find their parser has core dumped :-)
  373.  
  374. > In http://info.cern.ch/hypertext/WWW/MarkUp/Tags.html#z41
  375. > 45. The PLAINTEXT tag terminates the HTML entity. What
  376. > follows is not SGML. In stead, there's an HTTP convention
  377. > that what follows is a text/plain body.
  378. OK -- in.
  379.  
  380. > 46. "The text may contain any ISO Latin printable characters" --
  381. > this conflicts with the DTD. I think a design that treats Latin
  382. > characters as external data entities is cleaner than one that
  383. > treats them as text characters, but I'm willing to go the
  384. > other way.
  385.  
  386. I'm glad.  Lets.  I think that a full 8-character base will be  
  387. easier.  I think the text should be able to contain any latin 1.
  388.  
  389. > 47. "including the
  390. > tag opener, so long as it does not
  391. > contain the closing tag in full."
  392. > For Pete's sake, could we get this out of there once and for all?
  393. OK OK OK :-) I hope "The text may contain any ISO Latin printable  
  394. characters, but not the end tag opener. (See Historical note)" is OK
  395.  
  396.  
  397. > 48. "The <a  NAME="z22">XMP tag</a>..." Use the term "element". The
  398. > term "tag" doesn't include the content of the element.
  399. Done.
  400.  
  401. > In http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html
  402. > 49. "Special characters are represented
  403. > by SGML entities"
  404. > They're represented by numeric character references.
  405. > The lt, gt, and amp entities are not in the DTD. They should
  406. > be supported for historical reasons, but they are obsolete.
  407. I would like them in the DTD. While people are still reading/writing
  408. HTML they are useful. My mental ASCII table is in hex, not decimal,  
  409. anyway.  Are they any overhead? Why the war against them? For the ISO
  410. characters you wanted the opposite.  (Does your menatl ASCII table  
  411. stop at 128? Mine too)
  412.  
  413. Comments?
  414.  
  415. > In  
  416. http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/Current/HTML.html
  417. > 50. I'd like to move the Abstract, Specification, and the reference  
  418. to
  419. > "Text and Markup" up into
  420. > http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html
  421. > That node would look like
  422. > 
  423.  
  424. > <H1>HyperText Markup Language</H1>
  425. > <H3>Abstract</H3>...
  426. > <H2>Language Reference</H2>
  427. >     <A>Text and Markup</A>
  428. >     <A>The Elements</A>
  429. >     <A>Implementors' Guide</A>
  430. > <H2>Specification</H2>
  431. >     <A>the DTD</A>
  432. > <H2>Appendices</H2>
  433. >     <A>futures</A>
  434. >     <A>constraints</A>
  435. > 
  436.  
  437. > and this node would become "Implementors' Guide", with
  438. > pointers to recommended, complete, tolerated, errors,
  439. > libHTML, and SGMLs.
  440. > 
  441.  
  442. > In  
  443. http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/Current/html.dtd
  444. > 51. include ISO Latin 1 character set in SGML declaration?
  445. > 
  446.  
  447. > 52. Put PLAINTEXT back in HTML element (fell out by mistake.)
  448. > 
  449.  
  450. > 53. LINK element?
  451. > 
  452.  
  453. > 54. Get rid of H5 and H6?
  454. > 
  455.  
  456. > 55. Get rid of link TYPE lement?
  457. > 
  458.  
  459. > 56. Document BLOCKQUOTE in Elements reference.
  460.  
  461. This BLOCKQUOTE... it should be one thing or the other.
  462. If it cannot contain other paragraph styles then it should be a  
  463. paragraph style like address, and not be able to contain address.
  464. This is easy for everyone to implement.
  465.  
  466. If it can contain ADDRESS then why not let it contain anything - in  
  467. particular, headings. Trouble is, I can't represent that in RTF  
  468. easily so than blows the NeXT and Mac browsers. So let's
  469. make it 
  470.  
  471. <!ELEMENT BLOCKQUOTE - - (%htext;|P)+>
  472. like ADDRESS, and bear it in mind for HTML3 which will have SECTION  
  473. in, ie without the linear RTF constraint.
  474.  
  475. > 57. EXPIRES attribute on HEAD?
  476.  
  477. I toook it off .. its in HTTP2, as it applies to all formats not just  
  478. HTML.
  479. > 58. Get rid of NEXTID element?
  480.  Nope .. needed to stop editors reusing deleted IDs. See above.
  481.   
  482.  
  483. > 59. Document URN, TITLE, METHODS attributes of A element.
  484. Ooo yes. Done. Lots of "notes" attached for info only.
  485.  
  486.  
  487. > 60. Proposed Headers element (like a DL; for RFC822 message  
  488. headers:
  489. > <HEADERS>
  490. > <dt>To<dd>connolly@convex.com
  491. > <dt>Subject<dd>HTML todo list
  492. > </HEADERS>)
  493.  
  494.  
  495. Hmmm.
  496. 1. In fact, <DL COMPACT> looks very similar and has less narrow a  
  497. meaning.
  498. 2.In fact the headers inforation could rather be regarded as part of  
  499. the  metainfo in the <HEAD> element. Many of the RFC822 things will  
  500. in fact be outside the document in the HTTP layer.  This is a bit  
  501. chick-and-egg. Here we are describing an SGML dtd for a spoecific  
  502. format for a MIME_wrapped RFC822 body, and in it we want to put the  
  503. RFC822 header. Hmmm.  Something has got muddled. But I understand  
  504. what you mean: very often one quotes mail messages as text. Strictly,  
  505. one shouldn't though. You shouldn't be able to edit the headers.
  506.  
  507. Currently there is DL COMPACT which does that. It is implemented in  
  508. www. I am torn betwen generality and the preacticality of getting  
  509. something defined and outthe door and I thinkl the latter wins so  
  510. let's put COMPACT as an attribute for DL and leave the HEADERs if you  
  511. don't mind too much.
  512.  
  513.  
  514. > 61. List STYLE attribute?
  515.  
  516. No I don't think so -- see discussion #60
  517.  
  518.  
  519. > 62. XMP and LISTING: CDATA or RCDATA?
  520. CDATA is probably nearest to the original intention?
  521.  
  522. This is your stuff dan I think:
  523. > In  
  524. http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/Current/Text.html
  525. > 63. Under "Parsing Content Into Data and Markup," improve the
  526. > explanation of the MIXED, ELEMENT, EMPTY, CDATA, and RCDATA content
  527. > types (PCDATA is the wrong term) and how it affects parsing.
  528. > 64. Revise the section on the sample implementation, libHTML, and
  529. > supported.html.
  530. > 
  531.  
  532. > In http://info.cern.ch/hypertext/WWW/Test/test.html
  533. > 65. This node should be moved to the implementors' guide.
  534. Same coments as above -- moved in <PRE>
  535.  
  536. > In http://info.cern.ch/hypertext/WWW/MarkUp/Future.html
  537. > 66. Delete the reference to the perl script.
  538. done
  539.  
  540.  
  541. > 67. There are two references here to old versions of my spec.
  542. > 68. Header: it's in there: HEAD
  543. > 69. Highlighting: it's in there> 
  544.  
  545. > 70. Fixed width with anchors: it's in there: PRE.
  546. gone .. all gone!
  547.  
  548. > (get rid of HP1 etc. in Elements reference)
  549. No -- I will put that lot in another file though to keep it clean.
  550. There are some people (here) who geenerate a lot of HPs.
  551.  
  552.  
  553. > 71. Entities: Latin chars are in there. What do we need bullets  
  554. for?
  555. We don't.
  556.  
  557. > 72. Comments: the comment element is a bad idea. SGML comments are
  558. > documented and supported.
  559.  
  560. They are rather different in that a comment can surround a whole
  561. nested stack of SGML elements, and could ne nested. I don't suppose  
  562. SGML comments can?
  563.  
  564. > 73. Link types: we should look at HyTime before we go much further
  565. > on this.
  566. Well, there is only 9 pages on hhypertext in HyTime (More Time than  
  567. Hy) and in that I can't see any mention of link types.  As I said  
  568. above (with a different metaphor), I think this should be a well  
  569. defined and entrenched gate into uncharted terriory
  570.  
  571. > In the midaswww-1.0 browser: [by the way: I've fixed all these in  
  572. my copy]
  573. > 
  574.  
  575. > 74. HREF's with quotes don't work
  576. Foxed wth Tony's fix
  577. > 75. Unrecognized tags are treated as data, rather than ignored.
  578. > 76. numeric character references and entity references aren't  
  579. supported.
  580. Could you post diffs please for those Dan? Thanks.
  581.  
  582. > 77. ETAGO doesn't end XMP, LISTING, PLAINTEXT unless it's the right
  583. > GI. (e.g. <XMP>foo</foo> blah : blah should not be in the XMP  
  584. element.)
  585. > 
  586.  
  587. > 78. local: acess scheme is wierd. I suggest we go with ftp: and
  588. > local-file: to match MIME, and get rid of local: and file:
  589. Covered in another messsage.  I am prepared to split
  590. file to ftp: and local: even though there are many (decnet, afs,
  591. etc) ways to get at files and the client may be the best judge of  
  592. what will work for him.
  593.  
  594.  Now, what about the SAVEDAS adddress so that from justthe content of  
  595. the document hte partial UDIs can be resolved? I think that is a  
  596. useful thing, and could be essentail. I will put that in as Standard.
  597.  
  598.  
  599. > Well, that's all I can think of. Good night.
  600. I hope you slept well...
  601.  
  602. I have made a provisional list of link relationships. Ihope
  603. they show the utility of the attribute. They can always be ignored!
  604.  
  605. > Dan
  606.  
  607. Tim
  608.  
  609.